微服务和 Serverless 如何强强联合？
点击可观看精彩演讲视频
一、Serverless 带来的思考
今天的分享主要分四部分：第一部分，对 Serverless 的思考。第二部分，Serverless 在微服务体系中的位置。第三部分，Serverless 架构在腾讯云微服务体系实践中的应用。第四部分，Serverless 在腾讯云中间件领域的实践与探索。
首先分享关于 Serverless 的一些思考。企业级开发为什么需要 Serverless？我认为出于四个方面。
第一，研发效能。本身在 Serverless 化的过程中，传统上在容器有技术之后，CI/CD可能已经加速了，但函数技术让开发一个应用的时间大大缩短。比如明天上线一个运营活动，原来的情况下，要找开发、产品，开发完之后找运维，申请资源，部署服务器运营起来，到时还不知道能否扛得住。而现在研发效能提升，写一个代码提交就完成了。
第二，降低了整个基础设施的成本，这是我们 Serverless 化的主要目的，企业很关注这点。比如上云，原来不管运行多少服务，就算没有流量，服务器也要空着放在那儿。而 Serverless 可以自动规划这个事情，极大地降低了企业的整体运营成本。
第三，免运维。比如内部想做内部运营系统，研发成员不太愿意研发，因为这只是去管控现有的业务，在类似这种场景下，使用 Serverless 就能够降低运维成本。
第四，灵活扩展。以前开发业务的时候，经常讲到一个概念：前端把握后端。前面流量不能太大，否则会把后面的数据库压挂；或者消息队列不能写的速度太快，否则也会挂；所以前面要一层层限速。在 Serverless 架构之后，数据库的架构可以无限拓展。完全可以无成本，不考虑因为原来数据库写了一定的数据量就挂了。现在很多企业考虑 Serverless 是基于四种诉求的集中组合，研发效率，节约成本，灵活扩展的弹性，可能双十一来了之后有足够的资源，随时可以应用线上的业务。
接下来分享提升研发效率。整个研发流程，CI到CD，包括整个开发测试环境，多个环境的维护、监控，在 Serverless 的架构上可以提供整套加速业务交互的流程，加速业务价值交付的流程。
另外，降低基础设施成本。波峰波谷，一般的 Serverless 都是按照实际用量来计费，减少资源开销，包括更细粒度对资源分配的方式，提升资源的利用率，避免闲置。
第三，免运维。不需要提供准备服务器，做容量评估、扩缩容、维护服务器，无需操心服务器的各种性能指标和资源利用率，专注应用程序本身的状态和逻辑。如果发布新版本，避免旧的停机风险，随时克隆一套环境出来就行，运行新业务，都是可以缩短时间的。
第四，灵活扩展，主要有两方面。资源上，双十一或者618来了，现在很多云上的客户有大量的促销活动，提前申请一大堆服务器放着，过了双十一释放掉。另一种是不用考虑原来的数据库，考虑写的时候运用到一定规模，就考虑分步分秒，考虑加一个中间件，切分多个库，一个topic性能不够，要开始搭多套，同时应付性能的问题，这种灵活扩展在 Serverless 架构里面带来很大的变化。
另外，讲讲在整个企业级架构和 Serverless 架构演进的路线。看起来两个是不同的维度，但是其实有很多的相似性，企业级架构的转型，一般是单体架构，企业总线，SOA的架构，到现在一直很火的微服务架构，引进的主要原因，是原来单体架构下，包括IOE的架构，一台大型机的服务器慢慢进化到微服务架构的时候，成本不停下降。微服务架构的转型目标在降成本，把原来的单体拆分成微服务之后，单独对某一些微服务、某一些关键的业务逻辑，单独维护升级，原来一升级一大堆，容易出现风险。之前有一些客户说到，单体应用改一个逻辑测试了一个多月还不敢上线，微服务架构随时灵活扩展。Serverless 的目标方向也一致，即降本增效。Serverless 架构里面，原来还搬几个服务器放着，从裸金属进化到虚拟机再到容器技术。Serverless 往下进化的时候，更多在业务方面提供灵活性，成本不停优化，业务使用资源的成本两方面，它的目标都是降本增效，提升业务价值。
从我们的视角来说，全业务流程的 Serverless 架构是怎样的？Serverless 架构有FaaS、BaaS。FaaS是云函数，把很多的业务逻辑简单写两行代码线上发布，BaaS比如TDSQL-C可以做一些包括对象存储、消息队列等，随时买，随时用，根据业务的性能、请求量，不停做自动弹性伸缩，这是在后端的、底层的服务器 Serverless 化。那在FaaS、BaaS之间还有一层DevOps，说到这个词，大家可能会问，是原来的编译构建发布吗？我觉得缺了一部分，整个DevOps非常关键的环节——CO，持续的运行。微服务里讲到的服务治理、全链路的追踪、限流、版本发布，平时这些工作是谁来做？就是运维来做。微服务里强调治理的事情，其实不是落地到研发上，而是在运维上，运维要做很多业务级别的工作。如果把这部分工作提炼出来 Serverless化，是真正的减轻，对微服务整个体系价值有比较明显的提升。
中间这部分，通常在业务逻辑里叫全业务流程。一般我们的业务逻辑由几部分组成，包括很流行的所谓的中台架构，就是中间这部分。把公司内基础的重业务，微服务里面的沉淀重逻辑，在 Serverless 架构、FaaS里面沉淀那些经常由于业务的需求频繁变换的逻辑。轻业务和重业务做分离之后，不管基础的业务需求，产品怎么变，只要变化前面这部分就好了。后面这部分又提供无限能力的支持，这就是非常理想的在全业务流程 Serverless 架构的基础。
二、Serverless 在微服务体系中的位置
第二部分分享 Serverless 在微服务体系中的位置，我们在微服务体系中为什么需要 Serverless架构？
传统的微服务架构中有哪些特点？
1. 运维成本非常高。随着微服务化之后，微服务的数量增加，需要维护的技术设施在不停膨胀。一个微服务至少两个节点，做容灾，创建的配置，管理成本在不停上升。另外，微服务拆分的节点越多，服务间调用的复杂度越来越高。怎么去定位问题？运维成本非常高。
2. 部署难度高。提到部署难，会听到一些概念，全链路灰度、服务的甬道。在复杂的网状逻辑里面，假设现在业务发布，一定不会是把全套架构全部做灰度升级。一般变更一个逻辑的时候，都会选网状逻辑中的某几个节点、某几个服务升级，其他服务不动。这涉及到一点，怎么在变更的时候保证我的流量在那一版本上面做变更，但是又保证灰度变更不影响正常主观逻辑的流量？包括全链路的灰度，保证业务怎么做无缝，业务不中断，部署维护的成本非常高。
3. 资源利用率低。为了保证所有业务的高可用，不管微服务调量是多少，至少维护两个节点。很多容器里面可能还维护了两个4G，这是第一方面。还有一个非常隐患的问题，无法在微服务里面很好地预测，这个微服务应该有几个节点。在全链路的调用过程中，前面看起来没有什么，但是最终获取的关键节点。全链路的压测，判断出哪些是整个链路中的核心关键节点，这些关键逻辑节点要不要提前规划资源，开始没有什么，但是外面的入口某一个分支的流量突然涌上来的时候，突然导致这个节点资源不够，或者节点扛不住挂掉了。其实在整个的微服务架构里面，各个方面都会带有运维，资源预估、规划的问题。
Serverless 化和微服务化做一些结合，带来哪些好处或者它的特点是什么？
第一，不用再关心环境。因为 Serverless 让资源打平，可以随意创造多套运营环境，去做随意的隔离、销毁、管理。
第二，应用接入。不应该关心通常流行的很多框架，微服务有很多框架，这么多框架集中在一起，我们之前面过一个同学，说公司有三大框架，来一个腾讯的同学，开始用PaaS，来一个百度的同学用BRBC，阿里同学入职就用dabel，一个公司里面三四个框架都在跑，怎么做统一的运维和管理？多应用接入，多开发框架，多部署包怎么做？
第三，应用托管。全生命周期管理，应用的启停控制，发布、回滚等。
第四，弹性的底座。结合 Serverless、K8s，怎么去做这些资源动态的管理？
第五，弹性收缩。这部分是重点。它跟微服务，普通的HPA，K8s有什么区别？很多是基于资源纬度，就是CPU内存，磁盘堆积量，这是基于IaaS贡献的场景。但是基于应用场景，当这些资源如果没有的时候怎么办？如果写一个代码，自己的并发没有处理好，因为有锁，业务请求上来的时候，我的CPU和内存没有显著上升，但是对于业务上层看到的就是一直超时，这是应用的并发能力不够导致的情况，那怎么去做伸缩？应用并发能力体现在哪个地方？时间是一个纬度，请求量也是。应该自己去做结合，才能保证业务的可用性。
还有一种经常遇到的维度，消息队列。很多场景下通过消息队列做异步解耦，会面临一个问题，上有企业消息，下有消费消息，怎么定义下游应该有多少的资源去承接这个消费过程？如果定义少了，消息队列开始堆积，之前就有客户问我们，你们能不能根据消息队列的堆积量去给我微服务扩容，这就是另外一个场景的问题。
第六，可观测性。微服务里面做 Serverless 化是非常高的承诺，因为都不让我关心微服务器，出了问题怎么保证解决？现场出问题的时候，原来可以操作系统日志，现在不让我关心服务器，问题深入的定位和分析过程，有没有现场？包括应用级的可观测性的分析，都是很关键的问题。把这些问题都解决完之后，才能是完全靠谱的 Serverless 解决方案。
现在在 Serverless 整个微服务架构里我们面临一些挑战：云产品的集成，观测性，弹性的时效性。关于弹性的时效性，现在有很多技术体系平台，包括流行的K8s，腾讯有EKS，那么弹性时效性主要的点在哪？业界有几个 Serverless 关键的问题，有非常大的挑战性。为了给用户节省资源，能不能把它弹性到0，这是决定 Serverless 架构做得好还是不好的非常重要的区分点。对于函数来说，因为非常轻量，请求来的时候，再部署运行。但是如果做微服务化的 Serverless 时，是否可以把实例弹到0或者1，现在能做的级别也是最小只能维护一个实例。弹到0的话，请求过来的时候，应用没有起来，请求就可能失败。这是最大的一个时效性的问题。包括刚才讲的，应用的扩缩容，应用扩容的指标完善。
那么，基于 Serverless 下的微服务架构，我们的理解是怎样的？
1. 开发者可以自由选择任何语言、任何框架的微服务应用，专注于业务逻辑。
2. 微服务下的 Serverless 架构里面，分布式治理能力下沉、采用sidecar模式或者Node共享模式，把微服务常用的治理和业务逻辑无关区分开。
3. 支持业务构建任意的业务开发模式，比如有状态应用/无状态应用/事件驱动应用。
4. 接口标准化、业务逻辑下沉，技术下沉之后，跟业务层开放的就是一个非常标准的通用的常用接口。把通用能力通过标准的API提供给业务，通过简单的API操控底层的资源。支持标准API提供对分布式能力的抽象，通过HTTP/gRpc标准协议进行承载。
5. 支持服务依赖组件的可插拔，数据库能不能换？或者不依赖于云，支持对接各种云平台或者边缘网站。
6. 支持完善的可观测性能力，快速支持业务级的问题预测/发现诊断。
7. 资源运行的高可用，支持跨IDC，IDC挂了，能否跨可用区调度？可用区挂了，能否做到跨地域的高可用，我觉得这是微服务下的 Serverless 应该具备的特征。
新技术对于微服务的 Serverless 化带来很多优势，新技术主要讲的是Service Mesh以及Dapr。这个技术对整个微服务的 Serverless 有哪些价值？首先是可以让业务本身专注于业务开发。比如Service Mesh屏蔽了底层通信的复杂性，包括负载均衡、服务发现、认证授权、链路追踪、流量控制等等，让服务只关心业务逻辑。第二是多语言，本身能力下沉了，可以做到任何语言编写运行，随时运行。第三，简化应用开发流程，应用分布式状态的存储、事件驱动，可以用简单的API抽样给上层应用。第四，可移植性，把业务能力下沉之后，对于应用来说没有任何耦合，只要标准通用的API，可以进行多种云场景的支持。第五，可观测性，天然集成的日志、链路、追踪，包括可以轻松对接任何的组件、监控等。
三、Serverless 架构在实际中的应用
第三部分分享 Serverless 架构在腾讯云实际架构中的落地应用。
一是构建弹性微服务场景TEM，基于腾讯云，打造云原生标准可插拔的服务平台。它的优势是是可插拔，腾讯的资源可以插进去（按需配置无绑定、可上可下）；标准化，用户自我定义消息中心，消息队列等。整个的架构大概是这样，整个流量管理和服务治理，负载均衡，服务降级包括日志、监控等，都围绕业务本身，底层是腾讯云的EKS腾讯容器，构建整个 Serverless 化的场景，上面是API做整个的入口。
它有几个特点：
1. 构建无状态应用。Dapr通过标准的GRP协议通讯支持加密。
2. 开放了几种模式，可以选用下沉的模式构建，可以通过支持代理转发、流量管理等能力，也可以构建有状态应用、服务。Daper框架对接数据库、消息队列，提供了轻量级的接口，业务开发的时候应用这些轻量级的接口，底层的存储套件，可以把当前业务的一些已有状态，下沉到组件里面去。
3. 事件驱动应用。事件驱动可以插拔，可以通过暴露对外绑定的组件监听外部调用的方式，包括消息驱动的模式，完全可以支持。
然后是组件，可以跟腾讯云或者自建的缓存等服务抽象出一个资源组件，通过component自己声明需要哪些组件，通过声明的方式管理这些资源，我们会将这些资源与运营环境进行解耦，绑定资源的时候创建对应的数据库，在微服务里面依赖的数据库就都有了。最后，应用接入，基于Dapr运作，对于业务方来说是单独隔离的，不用单独地申请维护。
最后，微服务引擎。在传统微服务里，分为微服务的支撑侧、运行侧。支撑侧包括注册中心、配置中心、链路追踪系统等，我们把这部分做了 Serverless 化，无状态托管，自动免运维，做自动的扩容，进行可视化的管理。和刚才的TEM做在一起的时候，那就是一个全链路的 Serverless 化完整的架构。
四、中间件领域的Serverless架构
最后一部分，Serverless 架构在中间件领域的落地，在消息队列里做 Serverless 化。BaaS那层的 Serverless 化有很明显的特征：存储和计算分离。传统消息队列有哪些问题？我们面临几个场景问题，第一是性能的问题。现在云上去买一个托管的不管阿里云还是AWS，你买一个实例，它一定告诉你限定使用的峰值，为什么？因为本身没有存储架构分离的情况下，搭一个集群的峰值是由于搭这个集群的物理讯息或者物理机上限资源决定的。假设搭起来最多只有1万KBS，那云服务厂商提供的就是1万KBS，如果扩容只能迁移，买更多的重新搭一遍，这是性能的问题。
第二是topic，很多会在业务开发的时候面临这个问题，一个业务场景下定义一个topic。但是像Kafka这种消息队列的组件的源数据存储在CKA数据管理，自己本身能扛的数据量规模是有限的。一般像Kafka，1000-2000的时候到极限，扩容也解决不了。但现在SaaS化的场景，给每一个用户分布一个topic存储数据的时候，就面临问题。现在100万客户要生产出100万的topic，市面上很多做不到这一点。
另外，堆积。数据量没有消费走的时候，应该堆在后端堆着。但是这是物理上限决定的，物理集群如果存储只有500G，最多也只能堆到500G。如果不行，只能提供申配，搭更大的。对业务来说，是有感知的。堆在上限的时候，只能删掉，要不没有消费掉，要么淘汰掉，丢到队列里面或者换到另外一个地方去，或者删掉，因为磁盘满了不让写入。
那么 Serverless 上的消息队列，现在要解决，我们其实也是跟Pulsar社区深入合作。Pulsar对于我们来说是一个非常好的存储与计算分离的消息队列的架构，能够完美地支持，基于上面去做的这些基于云的资源。比如把broker存算分离之后，把消息队列的broker用容器化，用EKS做支持，这种情况下，性能的问题基本解决。再解决一个问题，broker本来依赖的CKI做一些去依赖化，包括Kafka社区在3.0里面马上发布的版本里面也是这样做。这样把topic上线的问题也解决了，所有的源数据以消息队列的存储，而不是以第三方组件去存储。包括堆积，放在云上的时候，把腾讯云的存储，比如COS对象存储，冷热数据做存储，热数据放在Pulsar里，把冷数据慢慢堆积到COS里，解决问题。
同时，基于Pulsar良好的架构设计，我们做很多协议的适配，之前说了，相信一个公司内至少维护两套消息队列集群。在这种基础上，基于Pulsar场景，很有可能换成一套集群，支持不同的场景，适配多种协议。现在我们在云上打造 Serverless 化的消息队列产品，主要就是四种能力，多协议支持、无上限的性能、无上限的topic（达到百万量级）、无上限的堆积（线性扩容、存储分离的架构）。
今天我的分享就到这里，非常感谢大家！
讲师简介
韩欣
腾讯云高级工程师
腾讯云高级工程师，微服务平台，消息队列，API网关等产品的负责人，负责中间件相关产品的规划，架构和落地实施。有超过十二年的研发架构经验，先后在腾讯、百度负责过腾讯广点通实时推荐系统，腾讯手机QQ空间，百度im+即时通讯平台，百度知秋智能客服等产品的研发和架构工作。目前关注在云计算中间件相关领域，致力于整合paas技术资源，构建基于微服务的技术中台，为企业的数字化转型提供基础支持。
推荐阅读
📚 看视频不过瘾还想要干货PPT？关注本公众号，在后台回复关键词「serverless」即可获取！